-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLIENT-SPECIFICATION: clarify fallback to english #4101
Conversation
Pulling my last comment #4092 (comment) here:
I think there are already too many optional bits to the language spec, and I think this one should be mandatory as it provides a consistent behavior across clients that do language (namely that they fallback to English). |
command line -> command-line when used as an adjective
@sbrl I edited two minor things. Other than that, the proposal is all good. |
I was suggested to engage in this discussion. Since this PR is about the specific formulation of the specification I added my suggestion to the #4092 (comment). |
@MasterOdin I completely agree about the fallback there. I'll edit. |
I haven't been following this discussion closely. I'll settle for whatever is decided here. |
Co-authored-by: Matthew Peveler <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check out the changes below @sbrl. Plus, I would suggest using @MasterOdin's suggestion since that seems the correct semantic for the LANGUAGE
env var, also adding a bullet point for this in the changelog.
Co-authored-by: Matthew Peveler <[email protected]>
Co-authored-by: Marco Bonelli <[email protected]>
Co-authored-by: Marco Bonelli <[email protected]>
Co-authored-by: Marco Bonelli <[email protected]>
Updates complete! |
Re-reading the env var paragraph, I don't think that explicitly requiring This paragraph is quite complex. I'll try to reword it when I have time to make it as simple and clear as possible so that you guys can tell me what you think, but in a nutshell I think we should just stick to the priority list of this documentation page, simply giving |
As i read the Note:-Part LANG must be present to enable the LANGUAGE variable. I tested it with % echo $LANG
de_DE.UTF-8
% gettext --usage
gettext: Unbekannte Option »--usage«
»gettext --help« gibt weitere Informationen.
% LANGUAGE=it_IT:de_DE gettext --usage
gettext: Unbekannte Option »--usage«
Usare 'gettext --help' per maggiori informazioni.
% env -u LANG LANGUAGE=it_IT:de_DE gettext --usage
gettext: unrecognized option '--usage'
Try 'gettext --help' for more information.
% LANG=en gettext --version
gettext (GNU gettext-runtime) 0.20.2
Copyright (C) 1995-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Ulrich Drepper. You may try this on your system. |
@columbarius Ok I see. Then the bottom line is: respect |
Thanks for spotting the typo @mebeim! I guess I'll hold off on merging until you've re-worded it? |
@mebeim Yes, respect My example with the gettext command, shows, that this is used for stdout, but stderr just uses |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for holding this back! As promised, I've tweaked the wording and reordered paragraphs to make the Language section clearer. See here for an easily readable version. It's fine to merge for me, if anyone has any comment and/or correction then please do let me know.
Co-authored-by: Starbeamrainbowlabs <[email protected]>
Since virtually every team member agreed with this, I guess we can merge it now? |
Sounds good to me @zdroid - go ahead :D |
As per the conversation in #4092, I've opened this PR.
I've changed the wording again a bit in order to comply with RFC 2119 and RFC 6919.